Business Analyst Community & Resources | Modern Analyst

Business Analysis in the Age of AI

Pulkit Singhal — Fri, 01 May 2026 19:24:00 GMT

Business analysis work has become faster and more efficient over the past few years. Requirements are documented more quickly, discussions are summarized sooner, and solution options are produced earlier in the delivery cycle than ever before. Yet many Agile and product teams are discovering an unexpected truth: as delivery accelerates, the importance of human judgment increases rather than diminishes.

The central question facing business analysts today is no longer whether tools and automation belong in analysis work, but where judgment must take precedence. That distinction matters because the most serious failures in delivery rarely come from obvious mistakes. They emerge from reasonable decisions that appear correct at the time and gradually move teams off course.

Where Acceleration Helps and Where It Falls Short

Modern analysis practices are excellent at speeding up work that is inherently mechanical:

Converting discussions into draft requirements
Identifying patterns across large volumes of data
Refining user story language
Summarizing customer or stakeholder feedback

When used well, this removes low‑value effort from the analyst’s workload. When relied upon uncritically, it creates the illusion of progress.

The challenge is not poor quality output. The real risk lies in outputs that are clear, structured, and confident enough to pass surface review, while subtly reinforcing incorrect assumptions. This is where judgment becomes decisive.

Judgment Gap #1: Determining Whether a Requirement Is Worth Building

Clear and complete requirements do not guarantee meaningful outcomes.

In day‑to‑day delivery, analysts encounter familiar patterns:

A requirement addresses a visible symptom rather than the underlying problem
Stakeholders agree on wording but diverge on expected results
A feature meets acceptance criteria yet produces no behavioral change

Experienced analysts pause to ask questions that artifacts alone cannot answer:

What decision or behavior is supposed to change as a result of this work?
If this is delivered perfectly and nothing improves, what are we missing?

Strong analysis is not just about expressing requirements well, but about challenging their intent.

Judgment Gap #2: Interpreting Context That Never Appears in Documentation

Business environments contain layers of context that rarely make it into requirements or datasets:

Organizational dynamics and power structures
Regulatory concerns driving risk‑averse behavior
Legacy failures that shape stakeholder trust
Competing incentives across teams

Analysts recognize these signals not because they are documented, but because they have seen the downstream effects:

Solutions that are functionally correct but poorly adopted
Processes that are bypassed in practice
Reports and dashboards that exist but are ignored

Judgment here is not guesswork. It is pattern recognition developed through exposure to real consequences.

Judgment Gap #3: Recognizing When Clarity Creates False Confidence

Early clarity is often welcomed as momentum. Detailed backlogs, well‑defined flows, and polished models can make teams feel aligned and confident.

Seasoned analysts remain cautious.

They ask whether clarity is reducing uncertainty—or simply hiding it:

Are assumptions being locked in too early?
What would invalidate this design once it is tested?
Are open questions being resolved, or quietly deferred?

Sometimes the most responsible decision is to leave things deliberately unresolved, even when tools and processes encourage premature finalization.

What This Means for Business Analysts

As delivery mechanics become faster, the value of business analysis shifts away from producing artifacts and toward exercising judgment:

Framing the right problems
Interpreting conflicting signals
Evaluating consequences under uncertainty
Challenging assumptions before they harden

These capabilities are not procedural skills. They are developed through experience, reflection, and exposure to real outcomes especially failure.

Closing Thoughts

Modern tools and practices have made business analysis more efficient, but efficiency does not replace responsibility. The most effective analysts are not those who produce the most artifacts in the shortest time. They are the ones who know when clarity is helpful, when it is premature, and when the best contribution is to pause and ask a different question altogether.

That work remains deeply human and central to successful delivery.

Reinventing the Annual Member Survey: A Business Analyst’s Role in Delivering Actionable Insights

Pulkit Singhal — Sun, 25 Jan 2026 02:38:00 GMT

In a competitive and rapidly evolving financial landscape, understanding member needs is vital to maintaining strong relationships and delivering meaningful value. Yet for many institutions, especially those with legacy processes, collecting structured member feedback can be surprisingly underdeveloped. This was the case at the Federal Home Loan Bank of Chicago (FHLBank Chicago), where — despite its extensive engagement with member institutions — the Bank had never before conducted a structured, enterprise-wide Annual Member Survey.

Recognizing the need for a formalized feedback mechanism, the Bank launched an initiative to design and implement its first-ever Annual Member Survey, leveraging Salesforce as the foundational platform. As the Lead Business Analyst, I was responsible for envisioning, architecting, and orchestrating this new capability from the ground up.

This initiative ultimately became a defining example of how strategic business analysis can create net-new organizational capability, not just improve existing processes.

The Challenge: Creating a Strategic Feedback Framework from Scratch

Unlike most process-automation projects, this effort did not begin with an existing workflow to analyze or improve. Instead, the Bank faced a unique challenge:

No prior survey process existed
No historical data or response structures were available to benchmark against
No distribution, tracking, or reporting mechanisms had been established
No governance model existed for how results should be consumed
Stakeholders possessed varying assumptions about what the new survey should accomplish

This meant the project required not only systems expertise but also conceptual design, stakeholder alignment, and strategic framing.

My Role as Lead BA: Designing a New Enterprise Capability

The absence of an existing process meant that Business Analysis would shape the entire direction of the initiative. My responsibilities included defining the business problem, creating the process architecture, establishing data structures, and ensuring Salesforce could support a sustainable and scalable survey model.

1. Establishing the Vision and Framing the Purpose

Through interviews and collaborative workshops with Member Strategy, Sales, Analytics, and Leadership teams, I led discussions to answer foundational questions:

What insights should the Bank gather annually?
How should “member satisfaction” be defined in measurable terms?
What KPIs would create genuine value for leadership?
How should results be tied back to member institutions in Salesforce?

This work produced the Bank’s first Survey Vision and Strategy Framework, guiding all subsequent design decisions.

2. Building the End‑to‑End Survey Workflow in Salesforce

Because no prior workflow existed, I architected a brand‑new process designed around clarity, automation, and scalability:

Designed the survey creation and distribution model
Built logic for survey-to-member linking
Defined the response-collection data structure
Modeled the end‑to‑end visibility lifecycle, including assignment, participation, reminders, and results
Ensured dashboards would give leadership real-time insights

The process not only captured survey responses but also embedded insights directly into the Bank’s member management ecosystem.

3. Translating Ambiguity Into Clear, Actionable Requirements

Given the lack of precedent, requirements had to be derived through deep analysis rather than comparison. I authored:

Detailed user stories
Acceptance criteria
Process maps
Data models
Reporting definitions

This documentation became the foundational blueprint for developers, testers, and end-users — eliminating ambiguity and creating shared understanding.

4. Leading UAT and Validating a New Capability

Because the Bank had never conducted a survey like this, UAT required additional rigor:

I designed test scripts covering every stage of the survey lifecycle
Trained business stakeholders on how to test a process that was entirely new
Triaged defects and clarified user expectations
Ensured the system was intuitive and future-proofed

Through this, the Bank gained confidence not just in the technology, but in the process itself.

5. Supporting Rollout, Adoption, and Governance

Beyond system delivery, I worked closely with:

Member Strategy teams to formalize interpretation of results
Analytics teams to align on scoring and reporting methodologies
Change management teams to ensure smooth onboarding
Salesforce admins to embed long‑term maintainability

This ensured the survey became an annual, repeatable, institution-wide capability—not a one‑off project.

Conclusion: This project shows that Business Analysts are not just process improvers—they are capability creators.By clarifying needs, defining strategy, architecting processes, aligning teams, and ensuring quality, the BA function enabled FHLBank Chicago to establish a powerful new insight mechanism that will shape strategy for years to come.

The Annual Member Survey is now more than a project deliverable.
It is a permanent intelligence asset for the Bank — built on a foundation of Business Analysis leadership.

DOR & DOD: The BA’s Compass in Agile Delivery

Jayaram.K — Thu, 08 May 2025 10:58:00 GMT

As Business Analysts in Agile teams, we often hear about Definition of Ready (DOR) and Definition of Done (DOD). But beyond the buzzwords, these two concepts are powerful tools to drive clarity, consistency, and quality in our work.

Definition of Ready ensures a user story is truly ready for development. It answers: Is this story clear, feasible, and prioritized? From a BA perspective, this means ensuring the acceptance criteria are defined, dependencies are identified, and stakeholders have aligned on the requirements. DOR is our quality gate before the sprint begins.

Definition of Done, on the other hand, ensures a shared understanding of what “complete” means. It’s not just about coding—it’s about testing, documentation, and meeting all acceptance criteria. For BAs, this includes validating that business rules are implemented correctly and that the feature meets user expectations.

Together, DOR and DOD are more than checklists—they’re alignment tools. They reduce rework, enhance collaboration, and help teams deliver value with confidence.

By actively shaping and reinforcing DOR and DOD, BAs ensure that requirements aren’t just ready and done—but truly valuable.

How clear are your DOR and DOD definitions today?

Embracing Agility: The Evolving Role of Business Analysts

Jayaram.K — Thu, 08 May 2025 10:52:00 GMT

In today’s fast-paced digital landscape, agility isn’t just a buzzword—it’s a mindset. As Business Analysts (BAs), we’re no longer just requirement gatherers; we’re value enablers in Agile teams. Agile empowers us to collaborate closely with Product Owners, Developers, and QA from day one, ensuring business needs are not just documented but truly understood and continuously refined.

Being Agile means embracing change. It’s about breaking down requirements into bite-sized user stories, prioritizing based on business value, and iterating frequently. BAs play a key role in bridging the gap between evolving stakeholder expectations and the team’s delivery capacity.

The beauty of Agile? It gives us a seat at the table throughout the lifecycle—not just at the start. From backlog grooming to sprint reviews, we help drive alignment, clarity, and continuous improvement.

In an Agile world, BAs must be adaptive, communicative, and user-focused. The goal is no longer just building the right thing, but building the right thing fast and better—together.

Let’s embrace the shift. Agile isn’t about losing control—it’s about gaining insight, speed, and collaboration.

Are you ready to evolve with Agile?

Secure by Design: Why Security Shouldn't Be an Afterthought in Software Development

Rianat Abbas — Sat, 04 Jan 2025 01:30:00 GMT

Building software products that solve actual customer concerns and generate business success is not an easy fit. Product executives battle strong competition, tight timelines, and high expectations, all while seeking to offer value. While success gives the opportunity to showcase approaches and frameworks, the reality is that building excellent products is rarely straightforward. As artificial intelligence continues to improve and incorporate into our daily lives, the sophistication of cyberattacks is also increasing. Recent occurrences such as the ChatGPT software leak and the Activision Blizzard data breach emphasize the critical need for stronger cybersecurity safeguards to be put in at every level of application and software development. Every product or technological advancement must have security built into its very foundation from the very beginning of its conception.
However, it is clear that implementing a reactive approach to security within software development is insufficient, as 77% of organizations reported an increase in cyberattacks in 2021, and 80% of successful breaches involved new or unknown zero-day attacks (often resulting from the exploitation of undisclosed vulnerabilities).
The growing number of security events emphasizes how crucial it is to give security factors top priority throughout the design and development of new products rather than considering them as a secondary issue. Many flaws and weaknesses that attackers actively take advantage of can be avoided by incorporating security into systems from the very beginning.

Recognizing the need for product security today
A product's security has a direct impact on its market performance in a time when customer trust is crucial. Consumers are increasingly aware of data privacy and the security of the products they use. This heightened awareness, combined with the rapid incorporation of Gen AI in products, requires a robust approach to managing product security risks. These risks can lead to compliance failures, operational disruptions, data breaches, and more.

What Is Secure By Design?
"Secure by Design" is a methodology that incorporates security into the foundation of product and software development from the start. This process ensures that strong, multi-layered security mechanisms are implemented at all stages of development, from original planning to deployment. Secure coding techniques are routinely followed, and rigorous testing is carried out to find and address vulnerabilities before products are released.
Organizations that integrate security early can guard against insider attacks, limit risks along the cyberattack kill chain, and avoid the reactive cycle of correcting vulnerabilities after launch. This strategy makes security an integral and ongoing part of the development process, rather than an afterthought introduced later in the cycle.

The Cost of Ignoring Security Early
Taking a reactive approach to security, which involves remediating vulnerabilities after a product has been built, has long been normal practice. However, this thinking frequently results in costly repercussions. Ignoring security during the early stages of development permits design flaws and security debts to build up, transforming easy remedies into complex engineering problems. Furthermore, post-implementation security testing may miss logic mistakes or workflow issues that were present during initial development, giving a misleading sense of security. By the time vulnerabilities are recognized, the underlying problems may be too deeply ingrained to adequately address.
The impact of security breaches on enterprises can be disastrous, which most times can lead to the following:

Financial losses: Cyberattacks result in stolen data, fraud, and operational disruption, which can cost corporations billions.
Reputational damage: For every breach that happened, it undermined customer trust, affecting brand loyalty and income.
Legal repercussions: Regulatory fines, lawsuits, and compliance violations can also add to the financial and reputational burden.
Operational disruptions: Security events affect workflows, lowering productivity and risking business continuity.

Integrating Security Into the Development Lifecycle
Products are designed to be resistant to emerging risks from the outset by proactively incorporating security into the development process. Throughout the whole development process, security is prioritized, which lowers vulnerabilities, increases product resilience, and builds customer trust. To properly integrate security into product development, the following steps must be taken:

Conduct regular security audits. - Regular audits of the code and infrastructure help identify and address vulnerabilities before they become significant risks. These audits prevent serious breaches by addressing issues early and ensuring that systems are secure against potential attackers.
Implement Secure Coding Techniques - Using secure coding methods such as data validation, encryption, and input sanitization reduces the likelihood of vulnerabilities. By taking these safeguards during development, teams may ensure the integrity and security of their products.
Use Frameworks for Secure Development - Using safe frameworks streamlines the integration of integrated security features, protecting products from common threats. This approach integrates security as a fundamental part of the development process and boosts productivity.
Train Teams in Security Best Practices - Teaching development teams about current security threats and trends fosters a culture of security-first thinking. Empowered teams reduce risks and enhance product security by making well-informed decisions that prioritize protection at every turn.
Stay Up to Date on Security Trends - Teams can proactively mitigate risks by monitoring evolving threats and vulnerabilities, safeguarding products from sophisticated attacks, and assisting companies in adapting to new challenges.

Security Considerations By Project Stage
Integrating security efforts with existing development workflows requires forethought at each product delivery phase, including:

Requirements Gathering: Perform asset identification and risk analysis and establish security goals. Build abuse stories showing attack vectors and threat scenarios.
Architecture & Design: Select inherently secure frameworks and components. Apply principles like least privilege and fail-safe defaults when detailing technical design.
Implementation & Testing: Adopt secure coding best practices. Perform static and dynamic analysis security testing to catch defects early.
Post-Launch: Run penetration tests mimicking real-world attacks. Set up monitoring for anomalous access patterns or errors indicating compromise. Establish secure update processes.

By mapping security concepts to existing development lifecycles, product teams more easily reason about where best to invest efforts for maximizing risk reduction at each stage.

Implementing Secure Software Development Lifecycle (SDLC) Practices
Secure SDLC is a methodology that integrates security best practices into every stage of the development process. Here’s how:
DevSecOps: This collaborative approach fosters seamless integration of security considerations throughout the development, security, and operations pipelines. By breaking down silos between development, security, and operations teams, DevSecOps enables a more holistic approach to product security.
Integrating Security in Agile Development: Agile development’s iterative nature necessitates embedding security testing within each sprint, ensuring continuous security evaluation. This ongoing focus on security throughout the development process helps to identify and fix vulnerabilities early, before they become major problems.
Security Checkpoints in Product Development: Implementing security checkpoints at critical milestones throughout the development lifecycle guarantees ongoing evaluation and mitigation of vulnerabilities. These checkpoints can include code reviews, penetration testing, and vulnerability assessments, ensuring that security remains a top priority throughout the development process.
By adopting these practices, businesses can significantly reduce the risk of security breaches and build products with inherent resilience.

Treating Security as a Core Requirement in Planning
Product managers play a crucial role in ensuring that development teams prioritize high-value work via a methodical planning process. While engineering leaders and product designers are typically engaged in feature planning discussions, security specialists are often excluded since security is perceived as a non-functional necessity that will be addressed later. This approach maintains the notion that security can be "layered on" after development, which raises risks and creates vulnerabilities. To address product risks and vulnerabilities in software development, product managers must prioritize security in the software planning process. This means that when discussing new features and functionalities, security experts should be involved from the start. Rather than adding security as an afterthought, it should be integrated and planned for from the outset. Product managers, like software engineers, data analysts, and user experience professionals, must master the fundamentals of security. Understanding the vocabulary and cooperating with security teams means that secure practices are built in from the start of product development, even if they are not supposed to be security experts.

Conclusion
Security is a foundational element of product development, not an afterthought or optional feature. Product managers and the entire software development team must ensure that security requirements are prioritized from the start, integrating them seamlessly alongside functionality and user experience. Security teams play a vital role in enabling this by offering best practices and actionable recommendations.
In an era of increasing cyber threats, treating security as intrinsic to design—rather than a premium add-on—builds trust and safeguards customers. By adopting proactive measures like early security analysis, secure design principles, and continuous testing, organizations can create resilient products that protect both users and their reputation in the long run.

Blueprints for Success -Pierre Hadaya talks business architecture and strategy

Agora Insights International — Mon, 29 Jan 2024 04:44:00 GMT

I really enjoyed the session with Pierre Hadaya as he talks business architecture, career planning, learning, strategy and more. I am struck by the depth and breadth of the conversation I had with Pierre, his reference to the concept of equifinality resonated with me on both a professional and personal level. The conversation was full of personal passion, professional experience, and forward-thinking ideas about the future of business and strategy.

n this post, I will share three key topics that stood out to me in the interview, along with a list of learning points that I believe are valuable takeaways for anyone interested in the evolving landscape of business and technology.

Background

Pierre, a professor at the Université du Québec à Montréal and co-founder of ASATE, has a long history in information technology dating back to 1995. He obtained a Ph.D. in Technology Management from the École Polytechnique de Montréal.

His primary research interests have culminated in a co-authored book, "Business Architecture: The Missing Link Between Strategy Formation, Implementation, and Execution." Pierre's use of the equifinality principle highlights his diversified career spanning academics, IT, and business architecture, affecting his competence in strategic planning and enterprise design.

In addition to his academic responsibilities, Pierre works with various private-sector organisations dedicated to developing world-class IT capabilities in order to effectively change their businesses and become more innovative and competitive. His consulting and advisory efforts are primarily concerned with IT strategic alignment through combined business/IT strategy and planning, as well as the implementation of an enterprise architectural methodology.

Three key topics from my conversation with Pierre:

1. The Role of Hobbies and Interests in Shaping a Professional Outlook:

Pierre's hobbies, such as traveling, reading, and watching movies, have significantly influenced his professional life. His love for travel has cultivated international relationships, while his passion for reading keeps him continuously learning. Pierre's appreciation for movies with complex narratives reflects his affinity for intricate systems and stories, a trait that undoubtedly benefits him as a business architect.

2. Career Trajectory:

Pierre's career trajectory underscores the value of embracing change and pursuing knowledge. He transitioned from engineering to IT, then academia, and finally to enterprise architecture and strategy. His story exemplifies the importance of adaptability and continuous learning in building a successful career. Pierre's approach to business architecture as a holistic discipline that integrates strategy, management, and implementation is particularly insightful.

3. The Future of Business Architecture and Strategy:

Looking ahead, Pierre envisions a shift from traditional, siloed structures to more integrated and agile systems within organizations. He advocates for architecture-based strategy, where agility is informed by a solid architectural foundation. This forward-thinking approach suggests that professionals must extend their competencies and embrace multidisciplinary methods to tackle complex business challenges successfully.

Key learning points:

Integrating personal interests with professional activities can lead to a more fulfilling career.
Continuous learning and embracing change are critical for professional growth.
Career paths are rarely linear; embracing a variety of experiences can lead to a more fulfilling professional life.
Effective business architecture is crucial for addressing complex problems and achieving long-term success.
Agility in business must be grounded in architecture to avoid inefficiencies and hindrances to progress.
Business architecture requires a balance of technical and soft skills, making it a multidimensional field.
The ability to architect complex systems is crucial in adapting to new technologies like AI.
A career is a marathon, not a sprint, and patience and persistence are key to long-term success.
Reading widely is important but applying what you learn is what makes knowledge valuable.
Choosing the right environment and mentors can significantly impact your career trajectory.

Conclusion

In closing, my conversation with Pierre reinforced the idea that our personal growth and interests are deeply intertwined with our professional lives. The future of business architecture and strategy demands a willingness to learn, adapt, and navigate the complexities of modern business. As we anticipate the changes that AI and other technologies will bring, the role of the business architect will become even more central in guiding organizations through transformation. The insights from this discussion are valuable not only for aspiring business architects but for anyone seeking a strategic and comprehensive mindset to navigate the evolving landscape of business and technology.

Interested in business architecture and business analysis certification and corporate training? Go to our website www.agorainsights.com

BA thoughts: Communication & Documentation

Iryna Babiak — Sat, 16 Oct 2021 07:49:00 GMT

Is Agile a reason to avoid documentation? I bet this question shows up again and again while working with product requirements. On one side, we have got long specifications, complicated diagrams, mystical technical design, too many prototypes and pretty obvious for engineers user guides (do we really need so much?). On the other side, can we actually cope with strict legal contracts, expensive functionality, large project teams, unstructured requirements and tight deadlines without structuring and organizing a scope of work? More and more agile teams take an extreme view of the Agile principles and they certainly do not see a value in documentation. The others tend to document everything in any case without a real necessity or reasons for it.

For better or worse, a need to document requirements exists and usually legal contracts complicate the process even more. For example, fixed price contracts require more formality, hard and detailed documentation beforehand, a smooth running at each phase of SDLC. There is no way you could survive without proper documentation on a project with fixed price contract.

When costs, scope and deadlines are difficult to define, Time and Material contracts would be more applicable. Usually in this case there would be less product documentation at the beginning, project processes would be less formal and more change-driven. Although there might be less product documentation, there definitely could be more reporting one. Such documentation is needed to provide transparency and visibility in spending resources.

In order to understand the overall scope of documentation that should be provided on your project, you should start with formal reasons to make sure you know what your project deliverables are. Internal documentation is also required as much as needed for maintaining a productive engineering process. Remember to document not more than necessary, and, at the same time, keep documentation as simple as possible.

The situation with communication in Agile is quite the opposite to the documentation. No one would deny that communication is given an important role in Agile, because Agile itself is built on effective and fluent communication. Agile puts less emphasis on formal documentation in favor of collaboration and communication between team members. Nowadays we can say, that communication is at the top of all managerial principles and is a baseline for building up relationships in any project team.

If it turns out that an engineering team and a client team do not have a clear view of what creates value for each other, that will eventually weaken their collaboration causing unnecessary delays and costs. Hence, open and clear communication can help create healthy working environment, which is a foundation for successful teamwork. No matter how hard it can be to establish proper communication at the beginning, it is something that will pay off in the long run. Proper communication can be defined by lots of criteria, but the most crucial are establishing your communication channels, creating a communication plan, not to mention arranging team buildings. Additionally, remember that overall, communication in Agile is built on team negotiations, feedbacks and decentralized decision-making. Allow different kind of decisions to be made at corresponding levels when product owners make decisions about the product, project manager – about the project, business analysts - about the functionality and requirements, solution architects – about the solution design, engineers – about implementation and testing approach, designers – about UX/UI etc.

It’s really hard to survive without face-to-face communication during COVID-19 period. Scientists say that it will likely to have a permanent effect on the way we live and work. Obviously, that is true, yet we keep increasingly incorporating digital and online tools into our working communication. Well-known tools such as JIRA, Confluence work well for more formal stuff. There are also a lot of tools for direct communication between team members or scheduling and conducting online meetings. What is interesting, we can observe the significant increase in using modern tools such as MIRO and MURAL. They help create documentation while communicating making this process even fun for participants.

What are your burndown charts telling you

Nick Stowers — Sat, 16 May 2020 06:34:00 GMT

Introduction

When I was introduced to scrum, the burndown chart was a tool that was highly emphasised however I feel the purpose has changed from it being a tool to predict (to a certain level) timescales for delivery to a tool that measures a team’s productivity…..in other words, the focus is on the number of points cleared which in my eyes, drives some adverse behaviours.

In this blog, I’d like to show some example burndown charts I’ve come across in teams I’ve been part of as a Business Analyst and what they should be telling you about how the team is operating. I’ll also offer some suggestions to fix what could be barriers to becoming that high performing agile team we strive to be.

So what is the purpose of a burndown chart?

A couple of quotes:

‘Burn down charts are a run chart of outstanding work. It is useful for predicting when all of the work will be completed’- Wikipedia, 2019 <https://en.wikipedia.org/wiki/Burn_down_chart>

‘The burndown chart is an essential part of any agile project and is a way for the team to clearly see what is happening and how progress is being made during each sprint’ - Mike Cohen, <https://www.mountaingoatsoftware.com/agile/scrum/scrum-tools/release-burndown>

We can take it from both of these quotes that the purpose of the burndown chart is to be able to visually see progress through a sprint, however I’d like to emphasise Mike’s point in his description that it ‘is a way to clearly see what is happening…during each sprint’. On many of the teams I’ve worked on, if not most, burndown charts are not reviewed at all but only looked at if someone outside the team wants to see them.

I’m well aware every burndown chart will have its own unique story behind it so when I give what I think are reasons behind the chart in the examples below, I’m only hypothesising from my own experiences. And while the burndown doesn’t tell the whole story, in my experience the analysing of them (with the whole team of course) has always improved the ways of working and that is the purpose of this blog.

Note: in the examples below, each sprint is 2 weeks long with the grey line depicting expected burndown with the red line the actual.

Example 1

The ‘Manhattan skyline’ burndown

Possible reasons

Ok, it’s not exactly like wonderful Manhattan but you get the idea (up and down peaks across the sprint). I think the two key parts of this burndown are the long flatlines at the beginning and midway through the sprint and the spike 3 days in. While this doesn’t affect the sprint points (what points/stories have been added have then been removed), it suggests the team weren’t confident of completing what was going in to the sprint for a significant increase (30 points). Or possibly, the stories weren’t ‘ready’ for the sprint. Also, have the team bitten off more than they can chew during sprint planning as there are 10-20 points left on the table at the end of the sprint?

How to fix

During sprint planning, ensure all the stories that are sprint candidates have met the team’s ‘Definition of ready’ and the team are confident that those stories that are being taken can be completed within the sprint. This may take some time for the team to get to this point as estimation and sprint planning (for me) are the two areas of Scrum that take most time before the team are comfortable with both aspects. And in my experience, if the team get these elements right (well estimated stories and confident planning), sprints tend to go pretty much as planned.

Example 2

The burn down-up-down-up chart

Possible reasons

I think it’s fair to assume this team is clearly having problems as you can plainly see but what might be the potential cause of this erratic burndown (or burn across!!)? Firstly, it’s clear the team have taken on way too many points for the sprint. Of course, there could have been an issue near the end of the sprint that caused the team to stop developing but even so, to fall short by 30+ points should be saying something. Long flatline periods suggests stories weren’t small enough to deliver incrementally. Large increases in points mid-sprint suggests the team have not been disciplined enough in saying ‘no’ to new stories being added. If these stories had not been added (20+ points), then the team may have achieved its target.

How to fix

Don’t be fixated by how many points can be done in a sprint. Just because the team did 60 points in the previous sprint, don’t assume the team can do it again the following sprint. I’m a big fan of Mike Cohn’s ‘Capacity-driven planning’ and I feel it’s the team’s responsibility to confidently be able to say, ‘yes, we can commit to everything in this sprint’. In velocity-driven sprint planning, I tend to see the thought process of what was achieved last sprint and therefore what stories can we cram in to achieve the same number of points or more. I think this approach is counter-productive and brings wariness to the team’s ability to confidently commit to the sprint. Therefore, ask the question, ‘what can we confidently achieve in this sprint?’ as opposed to ‘how many points should we do in this sprint?’

Example 3

The Flatliner

Possible reasons

My first thoughts on seeing this burndown was, ’should you even be using agile as a framework for delivering your project?’. I think you’ll agree that from day 1 of the sprint, 35 points have been added before work’s even started. Then there are no points (or virtually no points) cleared for 8 days before a big drop of 20 points and with still 40+ points left on the table. It could be this team is very early in its agile journey and therefore are unclear on their velocity (hence so many points) but still, loading up a sprint with no idea as to velocity suggests immaturity of an Agile delivery framework.

How to fix

In my view, the type of work being carried out by the team might suggest they’re unable to deliver iteratively and therefore may be better suited to a Kanban than a sprint approach. It could be they require the use of an Agile coach or Scrum Master for a period of time to set them on the right track and start from a position where they can clear what stories they take in to sprint and build up their velocity.

Conclusion

I hope those reading this are familiar with these types of burndown charts or if you’re new to Agile and you’re utilising burndowns, my point here is to make sure you use them to analyse how the team is performing and how that performance can be improved. Of course, your retrospectives are the perfect forum to do this.

I should make a couple of points though. Firstly, don’t look at a burndown chart in isolation. I’d look at the last 3-5 to see if there are patterns emerging before you embark on working to improve. Do they look the same or do they look completely different over a period of sprints?

Secondly, don’t place too much emphasis on them. You might think that’s odd as that’s what this blog is about however, as I mentioned, each sprint is unique and each burndown will have some sort of story behind it so use them as a discussion point for the team to improve, and not the be-all and end-all to improve the team’s performance.

As a Business Analyst, I nearly always find the reason why teams don’t deliver in small increments during a sprint, and therefore creating the burndown chart examples in this blog, is down to the user stories. No that user stories are the be all and end all but invariably I find it comes down to the stories either not following the INVEST model or them not being ‘ready’ for the sprint. If you get this part right then your sprints should run smoother and your burndown chart will reflect that.

So don’t ignore your burndowns (or burnups if that’s your preferred method), and if the team’s struggling to complete its sprints, spend some time analysing them to see where the team can improve.

Acceptance Criteria. Bridge from your User Stories to Code and Test Cases

Alexey Kiselev — Tue, 16 Oct 2018 14:44:00 GMT

We are writing User Stories to fix the scope and describe - what our application should do when implemented.User Stories are great, because the are:

Short,
Defining Roles,
A great connection of the requirement itself and a business need.

User Story declared as a high level definition of the requirement, but it could be used to specify a details as well, let’s have a look at the example:

US1. As a User, I want to book a parking space, so that will allow me to park my vehicle.

US2. As a User, I want to see closest to my current location parking structure, so that will allow me to find nearest parking without switching to the map view.

User Stories became one of the most popular artifact/tool to describe requirements and I would like to go deep into one of the key problems - User Stories details.

Problem statement

Key problem of the describing the implementation tasks via User Stories is their flexibility: single User Story could be implemented in too many different ways and there is no exact guidelines in terms of details of implementation for a single user Story.

As you can see, second User Story (US2) is a detailed requirement of the US1. Is it detailed enough to be able to implement it? If you got a skilled developer team, or this is a product with a common practices and UI guidelines, than my answer is “Yes”. Otherwise you should specify how this UI or JSON in REST API response should looks like, specify positive cases, negative, etc.

Solutions

Old style

I was a big fan of Use Cases and it could be possible to provide a detailed dialog between User and System to specify this US in details.

I will skip all these preconditions and the rest parts, also please don’t pay attention on my personal preference to keep 1-2 steps alternative flows in a main flow.

Here is a set of Use Cases, which covers my US2 in full:

Step	User	System
UC2.1	Click on the “Distance” column
UC2.2		If the “Distance” column is not sorted: Sort the column rows 0-9
UC2.2		If “Distance” column is already sorted 0-9: Sort the column rows 9-0
UC2.3		If the “Distance” column is already sorted 9-0: Sort the column rows 0-9

And I also prefer to show a mock up just to orient Development Team - where this feature should be applied. As you can see, I’m assuming that it will be a column “Distance” and I could decide - sort it 0-9 or 9-0.

Honestly, because my aim is to find a closest one parking location, there is no sense to apply 9-0 sorting, so, let’s purpose another one set of Use Cases:

Step	User	System
UC2.1	Open a menu “Sort by: Most popular”, “Distance”, “Price” >”
UC2.2		Show options: “Most popular”, “Distance”, “Price”
UC2.2	Click on the “Distance” column
UC2.3		Sort the available parking 0-9 by a “Distance” attribute

And this is how it should be implemented (this is a screenshot from the ParkMe web-site):

Nowadays dilemma

There are two main streams how to replace Use Cases with the Acceptance Criteria. Some theory first:

Acceptance Criteria are a set of statements, each with a clear pass/fail result, that specify both functional and non-functional requirements.

So, Acceptance Criteria got almost the same scale comparing to the Test Cases, as a User Story to the Use Case. Please note that Use Cases could be easily converted to the Test Cases, so there are a lot of common things here, but different format.

Anyway, let’s keep our focus on Acceptance Criteria. There are two main ways how to describe them:

Bullet points

This is a simplest way to specify what user should or shouldn’t be able to do:

simple and fast,
functional and non-functional requirements in one place,
non structured as minus.

Our example is a pretty simple one, so, let’s try to find couple acceptance criterias based on the Acceptance Criteria definition.

US2. As a User, I want to see closest to my current location parking structure, so that will allow me to find nearest parking without switching to the map view.

Acceptance Criteria:

AC2.1 System should sort parking structures based on the direction 0-9

AC2.2 User should be able to select sorting option from the list “Most popular”, “Distance”, “Price”

AC2.3 System must apply a sorting in a less than 2 second from the user’s click on the “Distance” option

AC2.4 System should not hide sorting options from the list. Example: If current parking structures list sorted based on the Distance, “Distance” option still should be displayed while user selects sorting options (UC2.2)

Still, an attached UI prototype or mockup helps to save some time for your developers and QAs.

Gherkin language

Simple and easy way, which I personally like much more than just a bullet list, because I prefer to keep everything in sequence like a dialog “Do” -> “Response” or a more complex “Given” -> “When” -> “Then” (aka Gherkin).

Gherkin uses a set of special keywords to give structure and meaning to executable specifications. I’ll skip a Background term below because it is not that popular and will skip headers like Scenario and Features because this is not a Gherkin tutorial.

Given: As mentioned above, given specifies the pre-conditions. It is basically a known state.
When: This is used when some action is to be performed. As in above example we have seen when the user tries to login using username and password, it becomes an action.
Then: The expected outcome or result should be placed here. For Instance: verify the login is successful, successful page navigation.
And: And is used to combine two or more same type of action.

At this point our Acceptance Criteria will have a next look:

US2. As a User, I want to see closest to my current location parking structure, so that will allow me to find nearest parking without switching to the map view.

Given user see the list of parking structures for they current location

When user clicks on the “Sort by” text

Then application shows next options: “Most popular”, “Distance”, “Price”

Given user sees next options of sorting available to select: “Most popular”, “Distance”, “Price”

When user clicks on the “Distance” option

Then application sorts parking structures based on the direction 0-9

And it takes no longer than 2 seconds to do the sorting

As you saw in my Use Cases example - I’m a big fan of tables, so I could easily convert this list into the table with Given, When, Then columns and ability to add AND statement inside of every cell of my table.

Key advantages are:

Structured information
Fast converting of your requirements to Tests in case if you got a Cucumber (Gherkin language based Test Framework):
- If you will use the same terms and phrases, you’ll make a QA guys life much more easier. Cucumber is able to understand that 2 equal statements like “And it takes no longer than 2 seconds to do the sorting” will have the same implementation of the test code, so it will help QAs to skip duplicate or similar code creation.
You should keep non-functional requirements inside of your scenario, and this messes up your structure even more than with bullet list concept. At this point, it looks like that keeping a separate non-functional requirements list is the best solution.

Conclusion

There are next key points I would like to highlight as a conclusion:

Major ways to specify Acceptance Criteria: bullet list and Gherkin Language (or rarely used structured process related terms like “Do” -> “Response”).
Bullet list is a more flexible and required less time.
Bullet list works better than a Gherkin Language for a low skilled BSA teams. Developers will appreciate something strict and standardized.
Gherkin Language is more complicated, but could improve quality of your requirements because of strict set of steps.
Gherkin Language significantly speed up QA effort and BSA-QA communication if company uses Cucumber/BDD.

https://automationpanda.com/2017/01/30/bdd-101-writing-good-gherkin/

https://akiselev87.wordpress.com/2017/07/24/cucumber-bridge-or-another-one-abyss-between-ba-and-qa/

https://rubygarage.org/blog/clear-acceptance-criteria-and-why-its-important

https://www.yodiz.com/blog/user-stories-acceptance-definition-and-criteria-in-agile-methodologies/

Author

Alexey Kiselev,

Lead BSA

https://www.linkedin.com/in/akiselev87/

Does Agile need Architecture to be successful?

EA Learning — Wed, 24 Jan 2018 03:21:00 GMT

On a recent Agile training course, the instructor opened the session by saying “Agile without a plan is just chaos!” I would like to propose that Agile without effective Architecture will eventually lead to chaos, particularly if organisations try to scale their Agile practices without some form of guiding framework.

The fundamental reason for this is that we all operate within constraints, which can be financial, regulatory, technical or customer driven. While Agile practices have traditionally been confined to software development there is a significant push by organisations, particularly at the Enterprise end of the market, to use Agile practices to manage traditional business functions. This new trend is euphemistically referred to as New Ways of Working. The benefits of leveraging Agile practices are numerous, with the fundamental benefit that organisations see Agile practices as a way to deliver improved outcomes for their customers and stakeholders, more efficiently and consistently.

There are numerous case studies citing the achievement of these benefits at a project level, but very few examples (to date) of successful Agile Transformations at Enterprise Scale. Proponents of Agile practices will point to the Spotify Model as proof that Agile Practices can be used to build a $13 billion Enterprise. Which is true, however, they didn’t do it without Architecture. They did it by leveraging Architecture and its practices as an enabler and not a governing framework. The way that Architecture worked within Spotify is quite different to how Architecture currently operates within Traditional Brick and Mortar Enterprises.

It is very hard to find a clear definition of the role of Architecture in Agile. The SAFe (Scaled Agile Framework) framework has done the most to identify the role of Architecture within an Agile environment. As with all things Agile the focus is to create consistent value and Architecture is no different. In SAFe they define two distinct elements of Architecture:

Emergent Design
Intentional Architecture

Emergent Design provides the technical basis for development and the incremental implementation of initiatives. It helps Designers and Architects to be responsive to changing customer/ stakeholder needs to ensure the initiative continually delivers value. At this level, SAFe practitioner’s see Architecture as a collaborative and interactive exercise through which the design element can emerge.

Intentional Architecture is a much more structured approach and more aligned to what many would identify as being traditional Architecture, that is a set of defined and planned Architectural initiatives which will both support and enhance the performance and usability of the initiative. In effect, Intentional Architecture is a clear recognition that we all need to operate within certain constraints such as choice of technology platform, financial budget, etc. If these constraints can be identified and incorporated into the initiative then the probability of the initiative being successful and delivering value is increased.

SAFe practitioners proport that by balancing Emergent Design and Intentionality Agile practices can be scaled to deliver Enterprise level solutions. In Safe, this combination is referred to the Architectural Runway which provides the technical foundation for creating business value. Which is in complete alignment with traditional views of Architecture.

The key to the success of this approach is the level of abstraction at which the balance of Emergent Design and Intentional Architecture occur. The fundamental behaviour that will determine this is collaboration. Architects need to be able to work productively with Agile Teams to provide fast and local support to manage Emergent Design while also helping Agile Teams to appreciate and navigate the constraints defined by the Intentional Architecture. One of the key attributes of Agile Practices is the fact that Agile Teams are encouraged to provide constant feedback to their stakeholders. As emergent designs develop Architects can use this information to adapt and develop the Intentional Architecture to ensure that the overall Architecture of the Enterprise is evolving with the organisation in the medium to long-term.

So does “Agile need Architecture to be Successful?” I would say the better question is “What type of Architecture does Agile need to be successful?” Agile requires Architecture that supports the way the Agile Practices deliver of outcomes (value). The type of Architecture that will do this will be a combination of a nimble reactive style of Architecture supported by a more traditional structured approach to Architecture. The challenge as with many things is to get the mix right!

Written by Scott Comte, General Manager of EA Learning.

To find out more about the EA Learning Business Architecture or Agile training courses please fill out the below form or click here to view our course range.

Modeling your way to a great backlog

Candase Hokanson — Tue, 31 May 2016 12:24:00 GMT

If you’re a business analyst whose company recently made the move to agile, you may be wondering where you fit in when there is no business analyst role. Or maybe you made the move to be an agile business analyst or product owner but don’t know how your traditional business analyst skills figure into this new agile world. Well the good news is that even in agile frameworks with no official business analyst role, business analysis still needs to be performed for every product so that we know we’re building the right thing. It may be called something else and we may do it differently, but it is still a vital part of the agile process.

With this post, I want to talk about one piece of business analysis - visual modeling - and how it fits into agile and building a great backlog. In waterfall projects, the business analyst will typically gather all the requirements up front (prior to design and development) utilizing visual models to enhance and give context to her requirements. In agile, we do everything with “just enough” detail, “just in time” for the development team to start working on a given requirement or user story, so many people have taken the route that the user story along with conversation is enough and we don’t need visual models anymore. This couldn’t be more wrong! Especially with so many large, global companies moving to agile and having distributed team with lots of dependencies, visual models can help bridge communication gaps that co-located agile teams can cover with conversation.

So, why visual models in agile? Visual models arguably are even more important in agile projects than in waterfall projects because there is a low cost to build or change them. They are easy tools to use to gain understanding between the business stakeholders and the development team without having to spend a lot of time writing requirements or user stories. Additionally, visual models allow the product owner or business analyst to view the whole product and vision while focusing on a sub-set for delivery - enabling the product owner to deliver the most value the soonest. Visual models are a great supplement to the backlog and user stories to gain a richer understanding of the product and the needs of the users. They also help the product owner or business analyst find missing stories and acceptance criteria.

Which models are best in an agile process? We have 22 visual models in RML®, but not all of those are useful all the time, especially on an agile project. However, I’ve found that there are about 5 models that are used on almost every agile project I’ve worked on. Let’s walk through each one - in this blog post, I’m just going to give an overview of each visual model, but you can find more information in the links below.

Business Objectives Model: The business objectives model tells the team why they are working on a project or building a product. It is similar to a product vision, but gives concrete objectives that we want to solve with the project/product. On agile projects, this is probably the most important model because the product owner or business analyst should be tracing every single user story back to the business objectives model to ensure that we are only building what is needed and useful to the user.

Process Flow: Process flows detail out a business process from the user’s perspective. They can be at multiple levels (typically L1, L2 and L3 - starting at the highest, most-abstract level and working down in detail) and so are great for agile projects! At the beginning of a project, the product owner or business analyst can define the L1, high-level process to identify epics or features, and as iterations progress, can dig deeper into L2 and L3 detailed process flows. Each step in a lower level process flow is likely to be one or more user stories.

Feature Tree: A feature tree is a visual model that lists out all features for a product/project in a hierarchical tree format. In agile, this is a good tool to keep up with requested features because it is easy to update. By color coding or making important features closer to the “trunk” of the feature tree, you can easily show iterations or releases.

Business Data Diagram: The business data diagram shows all data objects in a project or product and how they relate to each other. On agile projects, this serves two purposes: as a catalog of the overall data needs (hard to show in a user story) for use in building databases and as a source of acceptance criteria to enforce the relationships between data objects. This is a lower level model and may be started in a sprint 0, but would need to be kept updated in subsequent sprints.

Decision Tree or Decision Table: Finally, decision trees and decision tables detail out system logic and how the system should respond to various input decisions. These can be used to expand a given user story with decision logic or can be used as the acceptance criteria themselves. Since one of the most common ways of writing acceptance criteria is the “Given, When, Then” format, this lines up nicely to decision tables, where the “given” is a precondition, the “when” is a trigger or decision and the “then” is the outcome. Decision tables ensure that every combination of decisions and outcomes is considered, so when using these for acceptance criteria it is clear to the developers and testers what should happen in every instance.

These are the visual models I’ve found useful on my agile projects, which ones do you use?

The Case for System Documentation aka "Developer Is No Longer King"

Adrian M. — Wed, 14 Jan 2015 23:01:00 GMT

If you are managing a team of business analysts or systems analyst you probably have two main goals in mind:
- to make sure your team understand the requirements (the real ones)
- to make sure that you develop a solution which makes sense in the context of your constraints.

The chances are that one of your biggest constraints is a current system. Few of us have the luxury of working on developing brand new systems starting with a clean slate.

Most of us need to be able satisfy the new requirements in the context of an existing system. But do you know what the current system does?

Do you know the “AS-IS” of your system?

At the core of the Agile manifesto is the call to value “working software over comprehensive documentation”.

I could not agree more!

After all – what good to anybody is the documentation if the software doesn’t work?

Unfortunately many proponents of Agile development tend to miss the fact that the agile manifesto does not say “no documentation”. Whether this is by mistake or by design, I don’t know.

But I do know that, as a business analyst or system analyst, decent documentation made my life much easier and saved my clients a ton of money.

Let’s assume for a second, that the software does work… and that whoever specified and implement the first version did such a great job that the software satisfies all the initial requirements.

But also assume that there’s not documentation!

Now you are hired as the next business systems analyst and are being tasked to help out with the development of version 2 of the software. You might be able to do a great job gathering the requirements but when it comes to specifying what needs to change about the system – you’re stuck! You don’t know what the system does… Yes – you can play with the current system and try to infer what it does but unfortunately the only documentation is “the code”.

Let’s be honest – the technical landscape is constantly changing and most business analysts (even the technical ones) do not have the time or the inclination to maintain enough development skills so that they would be able to navigate their way through a number of technical layers (databases & stored procedures, middle layers and services, web server code and client side-script, etc.) a variety of languages (SQL, C#, JavaScript, Java, etc.), as well as a mixture of architectural models (Client-server, SOA, n-tier, etc.)

You are now at the mercy of the developers – and hope that some of the ones which developed the first version are still around.

These types of environments are the ones where the developer is King. The analyst finds himself at the mercy of those who can read code and navigate the technical layers.

I am not advocating that, as a business analyst or system analyst, you do not increase your technical skills; I’m just saying that, unless you become a developer, you’ll need some level of system documentation to point you in the right direction.

As a rule of thumb here are a few project characteristics which would indicate that maintaining live system documenting might be advisable:

the project is large (with a large team)

the business domain is very complex

analysis is done on-shore but the development is done off-shore

the system is supposed to be in use for years to come (i.e. there will likely be lots of turnover in staff over the years)

regulatory requirements exist which require certain level of system documentation (at least in the area of security, legal compliance, etc.)

building services or components which will be re-used by other teams (the clients)

I will be the first to admit that maintaining decent (good enough) system documentation is not easy. In large teams and large projects you must have the commitment of the management (the folks with the money) to maintain system specifications.

I have worked on many a project where the initial set of documentation was quite good but as soon as the first “emergency” arose, exception was granted to code without specs which were supposed to be updated “later”. In such cases – “later” usually never comes.

Another must for your organization, if you’re going to maintain system specs, is guidelines and standards. Whatever level you decide to maintain your specs you must create and publish a set of standards for your documentation. This way everybody knows how to read it and how to keep it in synch with the code.

Do you maintain system documentation? Why or why not?

Adrian

Agile investigated - Back to basics and beyond.

Victoria — Sun, 05 Jan 2014 22:24:00 GMT

The word “Agile”, there was a time when this word referred to the ability to move quickly, easily in a more tangible sense, and associated perfectly with synonyms like ‘nimble’, ‘acrobatic’, ‘light footed’, and it goes on and on.

Now in the context of software development the word Agile seemed to have gained new depths. Very much like the word “Tablet” originally referred to as measured amount of medicine, or a stone slab but now fondly associated with mobile devices.

In 2013 I began to get the feeling that Agile in the context of software development was more of a buzz word than anything else. Going through articles, job ads, seminars, and presentation papers, the word seemed to be carefully placed to suggest emphasis that good practise is been carried out here, or associated alongside other terms like Scrum, and or Extreme Programming (XP); in numerous places I encountered the following associations “knowledge of Agile / Scrum” essential, or “we work according to the Agile methodology”. Confusing right? I thought so. Somewhere in an attempt to perhaps impress, have we lost the true meaning of the term “Agile” in the context of software development. In a series of articles coming up in 2014, I go back to 101 basics and discover the true meaning of the word “Agile” with regards to software development. I explore published papers, investigate companies, and individuals that evangelise the Agile methodology. Like every other methodology it is a means to an end (the delivery of practical, quality software), but is it a one size fits all solution, or a classic solution as I have once been told, is it a representation of an approach, and where should this approach be best adopted, are there alternatives that work just as well, It will be great to identify truly how other just as buzzy words like “Scrum”, “Extreme Programming”, Kaban, Lean … really relate to Agile.

So what is Agile in a software development context?

Modern Analysis has it in its glossary as “a general term and conceptual framework used to describe a number of “light-weight” methodologies, such as Extreme Programming (XP), SCRUM, and Rapid Application Development (RAD), which exhibit a series of common characteristics. Some of these characteristics include iterative analysis and development, time-boxed iterations of a predefined length, delivery of the most critical features and functions first, delivery of a complete build with an initial set of limited features within a few months (often 1-2 months), small cross-functional teams usually of 6-9 team members, daily team communication meetings, and reduced levels of documentation.”

Telerik, a company that offers as a service tools for Agile project management and collaboration, simply refers to it “as a family of development process, not a single approach to software development”.

However we cannot begin to define Agile until we look to the source - The Agile Manifesto which states

“We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

From these definitions Agile should begin to take shape not as a separate entity for software development, or an association say to the “V model” or the “Waterfall model” or “Scrum” but as a concept that allows for the development of practical, quality software. Be it in Extreme Programming (XP), Scrum, Rapid Application Development (RAD), Lean, Kaban … it is the idea of creating better ways to develop software, while helping clients to achieve their business goals, without exploiting the talent that goes into such development, instead looking to develop partnerships. In the next article we explore companies that have adopted some form of Agile approach to software development, and explore a vital question, where does an Agile approach fit into small, medium, and large scale software development projects.

Applying Agile principles to requirement analysis

Ryan Thomas Hewitt — Mon, 27 May 2013 13:31:00 GMT

Background

The Agile methodology originated within the software development industry. Since its inception in 2001 – Agile has expanded beyond an initial developer-centric community – to being embraced by multi-discipline teams working across numerous industries.

The antecedent of Agile within IT was the Waterfall methodology. The Waterfall framework consisted of a series of sequential, discrete phases – with each phase conveniently mapped to a role/responsibly:

Analysis Phase -> Requirement Analysis (Business Analysts/Product Owners)

Design Phase -> UX (Designers/Usability Experts)

Development Phase -> Software Development (Developers)

Testing Phase -> QA (Manual Testers and Developers in Test)

Delivery Phase -> Release Management (Project Managers)

Due to the increasing popularity of Agile – requirement analysis has been encouraged to transition from being a stand-alone phase owned by BAs/POs – to become a project facet that can incorporate Agile principles.

In what ways can requirement analysis adopt Agile principles?

Collaborative requirement analysis

Prior to Agile – the practice of the development team being presented with an upfront, non-negotiable, detailed requirements document (BRD/functional specification etc) was common. With the advent of Agile – requirement analysis should no longer be restricted to the interaction between BAs/POs and the business – instead we should embrace collaborative requirement analysis:

A popular collaborative requirement technique is the “3 Amigos”. This process involves the developer, BA and QA discussing the requirement specification in a workshop. Each Amigo will offer a unique perspective – through discussions the Amigos will identify edge cases, undefined requirements, opportunities and potential reuse. The 3 Amigos technique can also reduce the risk of incomplete features being pushed into development by the product team – requirement specifications must be pulled into development when they have been reviewed and accepted by the 3 Amigos.

Collaborative requirement analysis facilitates a project-wide sense of ownership – and also communicates a common understanding of what features need to be built. Collaborative requirement analysis produces more robust specifications – and reduces the role-based silos that can exist on projects.

Detail as an emergent property

Agile artefacts such as technical spikes and development iterations mean that high-level requirements can be considered sufficient at project initiation. Low fidelity requirement assets (e.g. user stories /”back of the napkin” designs) should be employed on Agile projects:

Just-in-time requirements analysis (JITRA) has a concept that requirements should only be specified at the level of detail required for upcoming development. JITRA states that the further in advance of development requirements are defined – the more probable that requirements will become out of date, leading to rework and wasted effort.

Detail should emerge when it is required – which is typically towards the middle/end of the project lifecycle. Initial requirement analysis should be focussed on business justification and solution scope.

Embrace change

Specifications will evolve throughout the project lifecycle; all team members must acknowledge the benefit of responding to change. Adapting to changes in circumstances/urgency/understanding is crucial – requirement analysis should be considered an iterative rather than exhaustive process:

In terms of systems theory – project teams should be viewed as open systems. As the system will tend towards a steady state – change should be encouraged and communicated at an organisational level. Regular priority sessions, stakeholder workshops and competitor reviews should be used to mitigate resistance to change.

Incorporating feedback is crucial to the success of a project. Requirements are not unchangeable statements – they only reflect the current and expected situation, both of which are liable to change.

Necessary documentation

The adoption of Agile principles does not mean that requirements should not be documented. Requirement documentation is vital for developers, QA and the business stakeholders:

The principle of living documentation should be embraced. This means that all documentation needs to be accessible and up-to date. Business users, developers and QA should be able to request requirement changes. Documentation is most valuable when it is understandable by all team members, available and responsive to change.

Lightweight documentation such as feature files and high level process maps summarise the output of the requirement analysis process. The Agile methodology encourages appropriate documentation – superfluous detail is wasted effort; Agile does not negate documentation.

Continuous process improvement

Requirement processes should not be viewed as immovable obstacles. Instead these processes should evolve and adapt to meet the needs of the project. Where a process or artefact ceases to produce the expected value –it should be reviewed and changed by a self-organising team:

Retrospectives are a popular technique for identifying improvement opportunities. Team members meet to discuss what the team needs start doing, stop doing, and continue doing. Regular (every 2/3 weeks) and actionable retrospectives provide an open forum for continuous process improvement.

Requirement analysis processes (to-be-analysis, process mapping, stakeholder workshops etc) can always be improved. A technique that is effective for one team – may not be effective for another – or at least may require several modifications.

Continuous delivery

The Agile methodology promotes product iterations and regular releases. In order to align with this ethos, requirement analysis must produce a constant output – a steady flow of requirements will avoid the “big bang” requirement delivery that characterised the Waterfall methodology:

Minimum Viable Product (MVP) provides the scope of requirement analysis. The MVP will be delivered in multiple iterations – requirement analysis must be constantly baselined against the MVP and ensure that there is a sufficient specification available for each delivery.

Shorter delivery timescales encourages more frequent requirement analysis output. Specifications should be aligned to the MVP – features need to be deliverable and contribute to the MVP vision.

Conclusion

Iterative, collaborative Agile development has replaced the sequential Waterfall development methodology. Prior to Agile – the product team could hand over a list of detailed requirements – which would then be used by developers to build the product. In order to align requirement analysis with Agile development practices – the following principles need to be applied: requirementcollaboration, iterative specifications, embracing change, necessary documentation, continuous improvement and continuous delivery. By adopting these principles requirement analysis will transition into the Agile world, produce better specifications and ultimately lead to greater quality products.

Agile is an attractive word

David Wright — Mon, 29 Apr 2013 17:46:00 GMT

Agile is an attractive word. It means swiftness with discipline, with an emphasis on alertness to change in one’s external surroundings and quickly responding to change as needed.

The word I want to focus on from above is "external". A prime example of the difference between internal (controlled) and external (un-controlled) is an operating enterprise: business company, non-profit group and the like. The interesting problem for most enterprises is how effectively they control their own operations. The boundary between internal and external can become nebulous if control is lacking in parts of an enterprise. Control sounds like a bad word. It implies top-down definition of all aspects of enterprise operations. This can be true, but control can also include delegation of authority, with expectation of results without definition of methods used. Control is maintained, but authority is distributed. This is the sphere of business management practices, defined and changing and transforming from Henry Ford to Jack Welch. It is not easy, and many others have and will address it better than I, so I will reference them as need be.

The topic of interest here is the boundary between internal and external, controlled and uncontrolled, event and response… but not between knowable and unknowable. An enterprise needs to know what is happening around it in order to focus its operations on knowing what events are important, events that it needs to respond to. For these events, an enterprise defines processes/procedures to execute when triggered by events, to provide the desired results in response to the events; successful enterprises include those that recognize that the nature of events and corresponding processes change over time, sometimes very quickly. So, at any one point in time, an enterprise needs to be in control of its processes, but that control can’t stifle the need to change as fast as the world around it changes. Further, this rapid change needs to be accomplished without disrupting on-going operations.

What we are discussing here is Controlled Agility; the ability of an enterprise to respond swiftly to changes in its surroundings without losing its internal cohesion. The basis for controlled agility in an enterprise includes understanding that: - an enterprise runs on its processes, not its org chart - processes are composed of distinct activities and decisions - processes run on information, gathered and stored and used - processes are guided by business rules, especially when decisions need to be made. With this basis, an enterprise is well-positioned to be Agile without losing Control. It all comes down to understanding Change. Change comes in many degrees of impact to an enterprise. Consider workflow, which is based on process with roles and authority levels defined. If all loan applications over $100,000- go to Fred to be underwritten, the workflow will change temporarily when Fred goes on vacation. Those loan applications have to go to someone else until Fred gets back. This kind of change can happen frequently, but more importantly, it is a kind of change the enterprise knows can happen.

Frequent known changes are the heart of controlled agility. This is the kind of change an enterprise must be able to do, without changing itself, as part of operations. It should not need a project, especially an IT project, to make the change. Temporarily changing workflow might be considered a simple example, but it is actually an example of an overall type of change that can occur frequently, and that is business rule change. Business Rules are so embedded in how an enterprise works, it is actually a new and revealing approach to call them out separately. In a lender enterprise, it is likely a fact that “Customers may apply for Loans”, but “Customers may apply for Loans, only if they are 18 years old or older” is a Business Rule; it constrains an aspect of enterprise operations and, as said above, rules change (next year it could be 19 years). An enterprise that knows the facts and rules of their operations is well positioned to change rules as quickly as needed. However, rule changes still need to be controlled to avoid using incorrect rules to the detriment of the enterprise. Still, these changes should not require a project to change the structure of the operation and, again, not need an IT project. A major use of rules is to support making decisions. Loan underwriting across many financial lending/leasing enterprises is heavily rule-driven, the information about a customer and the loan product being used to decide to lend or not. These can be complex rules, or simply that the enterprise does not lend to anyone with a Credit Score below a stated value; and again, the rules will be changed over time as a lender tunes its underwriting, or is willing to take on more risk, etc..

Decisions also play a role in defining what processes/activities are used to respond to events. We all know of BPM diagrams with boxes for activities, diamonds for decision points, and arrowed lines connecting them all. A process may be composed of 20 possible activities, but less than 20 might be used in response to any one event because of decisions based on rules. What can change for a process? The number of processes in an enterprise, once all are defined, is relatively stable over time; new processes usually mean the enterprise has expanded its products/services to areas which need their own processes. Within a process, however, the exact activities that are carried out may change, or be re-ordered, or even be retired. It is the ability to change processes as quickly as possible, again without a project, that marks an enterprise as Agile. Changes in decisions and rules used in processes are the most frequent changes an Enterprise must do. Changes to the activities in a process change less frequently than decisions/rules, but often enough the agile enterprise needs to it as part of its operations. Are there aspects of an enterprise that are more stable? And are types of changes to them not necessarily known or predictable? This is a loaded question, because the answer is information or specific data used by an enterprise. Once all the information needs are known for an enterprise, these are very stable over time. The need to change information needs is similar to the need to add more processes; it happens when (as above) the enterprise is expanding into new products or services different from current products/services. To be more precise, information needs may change as the enterprise expands, but they may not as well; data requirements have been shown to be the most stable aspect of an enterprise.

So we have two ends of the change pendulum: from frequent and known, to rare and unknown. As said earlier, frequent known changes are the heart of controlled agility.

Satisfy Requirements with Continuous End User Involvement

Mendix.com — Thu, 17 Feb 2011 12:49:00 GMT

Perhaps the most important facet of agile software development is its innate ability to satisfy user requirements better, more accurately, more consistently, than what is considered ‘traditional’ software development. Where ‘traditional’ software development begs the user for all necessary information upfront and then reluctantly for feedback at the end of a project, agile development never lets the user out of sight.

This one differentiation separates traditional and nontraditional, slow and fast, waterfall and agile, 50% requirements satisfied and 100% requirements satisfied. The iterative nature of agile development forces engineers to go back to the user regularly, but more importantly, forces them to think of the user continuously. This interaction, and its psychological properties, is at the discretion of the platform employed.

While there are thousands of sales people that will graciously explain why one platform is more worthy than another, I will for once stay software agnostic and comment solely on the significance of the decision. As with any methodology, one platform may lend itself more appropriately to agile development (and the notion of continuous user involvement).

The stand ups, stories, and acceptance tests keep engineers in cadence with each other and the end user they aim to satisfy. Those very same end users that willingly provide their continuous feedback and involvement are under the direction of the decision maker responsible for your project. Your feedback loop with your end user is therefore their feedback loop with their supervisor.

So as the gears of your agile team continue to turn, they propel the internal gears of your client’s team, creating a centralized dependency on the accuracy, clarity, and knowledge of your end user. This person has a very good reason to be involved in your project, as you have a very good reason to keep them involved. The end result: software that satisfies the requirements of its users.

In office dialect: technology that satisfies the needs of the business.

By no means am I original in saying that the software development world has accepted agile development as a recognized response to decades of wasted time, sunken investments and fruitless skills. History (as unpredictable as it can be) tells us that steady adoption of new, speedier methodologies in young, innovative companies precedes its penetration into organizations of more portly proportions. In effect, the companies who adopt agile last are those who need it most.

Coaching Football and Agile Applications: It’s Game Time

Mendix.com — Tue, 04 Jan 2011 13:53:00 GMT

Many business analysts and heads of industry find themselves in compromising situations. Their team is down and they can’t seem to move the business properly towards the goal. It seems your competitor across the field is always one step ahead, providing results and fan [customer] satisfaction. But how did they do it and why can’t you come back?

Game Planning

This powerful opponent of yours has come up with a great game plan. The product they use – whether it’s the right gloves, cleats, breathable uniforms, etc. in sports – or a better system from order receipt, to entry, to delivery in business – is fundamentally better… but why? Did this opponent read the weather forecast and plan for adverse conditions? Are they just more talented with players or products that are just better suited for the game? Do they have systems in place that allow for adjustment depending on what is working and what isn’t?

Adjustments

Many of us head into planning a certain way based on what we have and who we’re up against. Let’s say you’re going into the match against the #1 passing team in the league. You spent the whole week practicing your nickel pass defense with plans to stop their attack. But what happens when you get into the game and you realize that their third string ball carrier is a beast? He’s tearing your defense up all over the field. Do you continue to play the pass even though they are running on every single down? No, you need to adjust your game to play with them.

In business it’s the same way, let’s take the classic example of the traditional video store. For years it was all about having the largest selection, being in a convenient location, and providing rentals at a reasonable price. In comes a new team with a new strategy, let the customer handle every transaction online without ever having to leave their house. Some of the traditional storefronts adjusted, downsizing locations and adding a similar online offering to their large customer base.

How does this all tie together?

Much like the coach that is able to switch his defense to line up eight in the box against the team running all over them, the large video store needs to be able to position itself against a competitor’s strategy. But what if this company doesn’t have the ability modify its business strategy? What if they need a complete overhaul of its application infrastructure to do so? This is going to cost the business large amounts of time and money. The money will absolutely have to be spent if the company wants to stay in the game for the long haul. But what about the time it takes to develop the application?

Many of the mid-sized video providers didn’t have the brand, size, nor money to bridge them into this new age of video rental. By the time they were able to come to market with a suitable offering, they were competing against the other small companies who also didn’t adapt fast enough. Do yourself a favor and build your original application on a platform that is agile and can change with your business needs. That’s the moral of this story – agility wins.

Challenges with User Stories

Seilevel — Mon, 22 Nov 2010 17:44:00 GMT

A Promise to have a Conversation

I’ve been writing user stories for a couple of years now, and the best way I’ve heard how to describe them is that they are a promise to have a conversation. Enough information should be written down to give the reader an idea of what the gist of the story is (and to be able to roughly estimate a story point size to it), but the details are to be driven out during discussions between the product owner and the development team at the start of the sprint.

And that concept works well when the product owner and the development team are located in the same location. As a product owner, I could attend the daily scrum meetings; I was available to the developers/testers/technical writers to answer questions as they arose.

Recently, however, I’m working on a project where the development team is not located with the product owners. In fact, development may be done in several different locations around the world. This introduces several layers of complexity that a co-located team does not have. Not only is there distance differences between the various team members, but now we also introduce time zone, language and cultural differences as well. As a result, there is a greater documentation requirement than I have had to deal with before. While the promise to have a conversation still holds, the product owner is just not as available with a geographically diverse team.

Story Size – Large vs. Small

So one of the first hurdles to jump was what the appropriate size of the user story is. I’ve had some interesting conversations with various people about this topic, and opinions do vary. Some feel that user stories should tell an end-to-end story. But that can result in very large, very complex user stories. I do see value in these user stories, and I tend to call them epic stories. I prefer to take these epic stories and break them down into much smaller user stories.

One characteristic I try to keep in mind as I write a user story is that it should be small enough to be developed during one sprint. So it is critical to understand the size of the sprints within your organization, since I’ve heard of sprints lasting anywhere from 1 to 6 weeks. It also helps to get your development organization to provide you with some rough story point sizes, so you know if your stories are of an appropriate size or not. For any story that has a point size estimate that is larger than the velocity of the team during a sprint, that story needs to be broken down into smaller stories.

What to do with Business Rules?

Another challenge is business rules. With the project that I am working on, we have finished documenting the user stories, but they only tell part of the story. They tell what the user expects to see, but not how the system gets to those results. That is the role of the business rules.

Now, if the team were co-located in the same location, this is where the promise to have a conversation would come in. During that conversation, the business rules can be vetted and discussed. However, with the geographically dispersed team, much of this needs to be written down. The story and the business rules can still be discussed, however, with cultural and language differences, having something in writing for team members to read through before the discussion and to refer back to after the discussion is a necessity.

But what is the best way to document these business rules? Some can be documented with the acceptance criteria for the user story. But sometimes there is the additional needs to get even more detailed than that, to get to the actual “if, then” statements. Where is it best to document them? I don’t have an answer to that yet, and much may depend upon the tool chosen to store the user stories.

But I am certainly interested in your experiences…how have you solved this problem?

Let us know, or check out other posts. http://requirements.seilevel.com/blog/2010/10/challenges-with-user-stories.html

The Agile Application Assassin

Mendix.com — Tue, 16 Nov 2010 13:51:00 GMT

You know, it’s the coolest nickname I’ve ever received - but it almost sounds negative. I mean am I going in and assassinating your application? No, I go in and make the changes you request and re-deploy your application. So why give me that nickname?

Pretty easy I guess, when I’m operating strictly as the implementer of a solution, I am able to focus on functionality and how I can improve it. Typically during meetings I write all the customer requested changes down and begin implementing them once we move past that section of the conversation.

Recently during a phone call with a client I was able to test drive the new functionality I built for them in the day prior. Once we went over it all and they gave me their feedback I went to work to make it happen. The online meeting switched to talk about other status reports for members outside of our organization.

By the time they were done I had made the necessary changes, re-deployed their model, and was able to have a second round of test driving during the same meeting. The customer was astonished to see these changes happen so quickly that they dubbed me the “Application Assassin”. “Seriously, how did you do that so fast? Did you already have a different version in mind?” No, I just have the Magic of Mendix. Drag, drop, double click, and deploy…….it’s magic! Maybe the nickname should be the “Application Magician”.

Sometimes I’m truly amazed by how quick it is to write and change full applications so fast. But I guess when it’s all visual and no coding it’s easy. Consider this story the next time your business needs have you in a strait jacket wrapped in chains. You may want to have a magician (we still prefer Business Engineer) on your side. That way when the realization is made that your approach should be different, you will be ready.

Moving to Agile Documentation – why ‘Pair Inspections’ make sense

FergalMcGovern — Wed, 03 Nov 2010 11:00:00 GMT

One of the more controversial techniques fostered by some in the agile community is ‘Pair Programming’. It is a practice that originates from Extreme Programming, a specific Agile process pioneered by Kent Beck.

It is controversial, particularly for larger corporates because it seeks to adjust human behaviour patterns. In Pair Programming, developers sit side by side, sharing one machine and working in teams of two at all times on a single code base. In reality, it is one of the agile techniques that is likely least adopted and most controversial among programmers for a variety of reasons, mostly cultural and behavioural in nature. Most fundamentally, for a team to be successful at pair programming takes a lot of hard work. It’s a bit like a marriage really, personality compatibility is a key pre-requisite and just like marriages, the best work well but not all will be successful.

Pair Programming in action

The point of this post is not to get into the specific argument as it relates to agile developer activities for code, but rather to propose something that Project Managers and Business Analysts should actively consider for documentation and that is what I will call ‘Pair Inspections’ or PI.

The issues I have found with larger document sets in lager initiatives, especially larger documents such as BRDs and Detailed functional specifications and Test Plans is that they are:

generally authored by one and only one person with one vantage point
are worked on for a concentrated period of time by one person
do not combine the considerations of other relevant stakeholders
if inspections are going on, they are at a particular point in time, typically at a phase gate and are not that effective at spotting real issues. Infrequent code inspections suffer the same fate in my experience, if I reflect on my time running engineering teams

Now, I am not suggesting that we have co-authoring sessions for a single document. The nature of MS Word and the fact that many people are distributed make this in many cases impractical.

What I am suggesting however is that documents are reviewed actively & informally as part of the authoring & document production cycle. Let me suggest some simple measures that would achieve this:

Frequency: Conduct a Pair Inspection once a week. This may be ‘analysis phase’ in waterfall, or pre-sprint stage in Agile
Alternate stakeholders: Every other week try to include a stakeholder who wears a different hat, e.g. pair a BA with a Test Lead, pair a BA with a PM
Distributed Teams: For distributed BAs working in remote locations, use collaborative tools such as webex, gotomeeting or livemeeting.
Consistency: Put a solid recurring meeting in your calendar every week at the same time and take it seriously
Informality: Make pair inspections a way to gel stakeholders. Don’t impose rules but let the inspection process ‘self-organise’

The net effect is that substantially better documentation results when active & collaborative inspections and reviews occur, regardless of whether you are in a waterfall or agile environment.

Applying the above simple steps tightens document quality in very material ways.

------

Fergal McGovern, Founder VisibleThread.

See our main blog at: http://www.visiblethread.com/blog/

Enter the Business Engineer: Part 2

Mendix.com — Tue, 19 Oct 2010 19:36:00 GMT

In a previous post regarding the emergence of the Business Engineer, I discussed the Who, What and Why of this new type of human capital. At Mendix, we see them growing in numbers, most likely due to the nature of our software. If you’re going to give business analysts the ability to develop software, or developers the ability to communicate business – you’re going to see doors open and walls collapse on either side of the business-IT equation.

The BA

In order to figure out exactly where BE’s come from, so that we can harness their powers for the greater good of business agility, we’ll have to know more about their closest relative – the BA. According to The International Institute of Business Analysis, the role of a business analyst involves: “the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization and to recommend solutions that enable the organization to achieve its goals.”

Well isn’t that something. All of those tasks and techniques are funneled down into a recommended solution and passed along to the technical wizards who turn requirements into reality. I’ve always wondered whether the less-than-technical BAs wish they could, perhaps just once, finish the job and deploy an application. Perhaps they’d hate to deal with code, I’m not sure. What I am sure of, however, is that business engineers dream about models (business-models, pervert!) and how great it would be if they could get requirements and deliver solutions, on their own.

The BE

Call it selfish; call it futuristic; you can even call it a pie in the sky. With the emergence of the business engineer, demand for agile software development, visual modeling tools and a revamped SDLC is truly explosive. Based on the definition above, the BE is not really related at all to who we now know as the business analyst. Though I mean not to offend nor aggravate business analysts or software developers, I must assume that they see the astronomies of their value propositions colliding.

So then, if the business analyst recommends a solution, it must be the business engineer who implements it. And if the business analyst plans the solution, the business engineer deploys it. I may even go as far as to say that business analysts identify the problem, where business engineers solve it. This fine, yet drastic and seemingly impossible, line – is growing in organizations everywhere.

What’s Next

As I mentioned in part one of this series of posts, the ambiguity of the business engineer is becoming more believable with every Mendix user. What was once called impossible by technologists is now championed as magic by audiences of our ‘proof’ of concepts, and we’re betting will one day be considered the norm in enterprise software development. In the meantime, collaboration between business and IT may remain segregated by occupational obstacles inherent to aging technologies and ancient practices.

The current generation of business and technology students is likely to pave the way for career paths in business engineering. Courses in business engineering will be taught by today’s business engineers, and until then, these heroes of enterprise software can only enlighten their organizations with a glimpse into the future of business agility.

Telecom Companies are ready for the Cloud

Mendix.com — Mon, 20 Sep 2010 16:26:00 GMT

Telecommunications companies are looking to cloud computing to clean up inefficient processes throughout the sales channel. The products and services in this industry change so often that these companies have become more competitive than ever, with continuously shrinking margins. Flexible front end solutions bring agility to the sales process, providing a future proof solution to front office and extended enterprise portals. As the masses continue to frenzy over new data pumping smartphones, internet connected television, and television connected internet – these organizations continue to face seemingly unparalleled challenges in business agility.

So begins the first of a series of blog posts titled “Telecom Channel Portals 2.0” in which I plan to discuss a few interesting ways that telecommunications companies will benefit in a new age of software. Software as a service is fundamentally changing the cost structure of information technology, and industries in which competition for profits is the fiercest will ultimately be the earliest adopters. The following three applications are common areas of interest for telecommunications companies looking to enter the Saas realm.

1. Marketing Portals

When products and services change as often as they do in the telecommunications industry, disseminating that knowledge throughout agent channels (partners and direct marketing/sales people) is extremely important. Marketing portals give agents and resellers access to up-to-date information from any browser. Sales in this industry are driven by intensive campaigns for which supporting marketing materials and product/service catalogs need to be readily available. There is no better way to manage and to provide this information to agents and resellers than via an online portal.

2. Quoting and Order Entry

Online portals for quoting and order entry increase direct business value for telecom providers and resellers. On either side of the equation, stakeholders get data faster and more accurately, which speeds up customer acquisition while minimizing costs. Telecom providers become more attractive to partners, and the list of benefits goes on and on. By making it quick and simple for the sales channel to give and take information from their provider, business agility is greatly improved.

3. Commission Automation

Online portals can go much further than displaying and collecting information. By including logic into an application, the functionality and time saving capabilities become endless. All too often, we see gigantic excel spreadsheets used for finance-based processes such as tracking commission payments. By automating this process, time is saved, errors are avoided, and transparency is increased. Online portals can be automated and customized for recurring commission structures based on the type of partner and product/services being sold.

These are just three ways that online portals are changing the way information is managed in the telecommunications industry. The reliance on information is so great that adopting cloud computing is almost inevitable. Keep an eye out for more “Telecom Channel Portals 2.0” posts on the Business Agility Blog.

Mendioms for Business Analysts

Mendix.com — Wed, 01 Sep 2010 13:04:00 GMT

A Mendiom is an idiom with a Mendix twist. This is the first of a series of posts with Mendioms for different types of people. This week, we have chosen a few of our favorite Mendioms for business analysts.

Business analysts are an important part of an organization’s business agility. By having the responsibility of communicating between business and IT, business analysts can greatly reduce time to market of new solutions by using agile development methods. In an effort to both inform and entertain, here are a few slides for my business analyst readers.

Visual Modeling – Stopping IT Failure at the Root of the Cause

Mendix.com — Tue, 17 Aug 2010 12:40:00 GMT

I came across this slideshow from CIO Insight a few weeks ago. The aggressive-looking deck attempts to explain why IT projects fail. I’m always a bit weary of headlines that seem this simplistic, but who knows – maybe they thought up some new ways to blow a project that millions of us hadn’t already avoided, accomplished, or observed. Better yet, wouldn’t it be something if we finally figured out how to diminish the “63 billion dollars” worth of failed projects in the US?

Clicking through the deck, I realized that a majority these reasons are somewhat interconnected. It’s not just lack of detailed requirements, lack of user involvement, scope creep, bad scoping, poor testing, or lack of executive support. An innate segregation between the business people who use the product, the IT people who build the product, and the business analysts who dance in between – is the root cause of most of these problems.

Enhance Collaboration, Improve Requirements

The logical solution to these failure-inducing practices is visual modeling. By using visual models, both sides of the IT-Business equation have a valuable representation of what the IT project will encompass. By using this method of collaboration, requirements become more accurate. Business people can visualize the processes that the software will benefit, and IT people have a more functional way of communicating their solution.

The Immediate Feedback Loop

If we take one step further into the initial requirements analysis, these visual models can be deployed as applications for an immediate look into future checkpoints in the project. Imagine the following scenario:

Business Analyst: “So the data from your current ERP system will be aggregated and validated in the new system, which will then report directly to their corresponding contacts from your CRM.”
Client: “Right…”
Business Analyst: “Ok, well this is the model with data flows – and this is what the application will look like to the contact in the CRM system.”
Client: “Wait, that’s not all the data they’re going to need. What about integrating the grant management database?”

[A few clicks, a new form, and deploy.]

Business Analyst: “Okay, so now the window shows the corresponding grants for each contact as well.”

Isn’t immediate feedback fun!? It’s a dream for business analysts that has only recently become a reality (in the Mendix Business Modeler, that is). Mendix users never come close to failing a project because clients know exactly what they’re getting and developers know exactly what is needed. So why are so many IT projects failing? The right tools are out there, it’s only a matter of time before they are discovered.

BA World Sydney - A review

Craig Brown — Tue, 27 Jul 2010 00:31:00 GMT

I went to the Business Analyst World Conference in Melbourne on the 19th and 20th of July. Like last year it was a great event. On day 1 I spent the whole day in one room (introducing speakers.) and got to listen to three very different stories.

Matthew Coppola from Perth training outfit Paramount Training gave a talk on Understanding Strategic Planning.

It’s always useful advice to go back to basics: Where do you want to be? Do you understand your capability? Mathew’s talk gave a simple framework to drill into these two questions. (See a transcripts of the whole talk here.)

Something that struck me while listening to his talk is how odd the world is. So many of us profess to know this stuff, but when you get out into the pressure of deadlines and complicated personal relationships – how many of us stick to the agenda and define the problem sufficiently before getting into implementation mode.

The second talk I saw was by John MacLeod of IBM’s Rational team on Steps to Better Requirements Management. This was the basics of requirements management: Start with a technology neutral business requirement statement, evolve it into a solution constrained by a particular IT or system scope and finally resolve it into specific statements of functionality. And trace things from front to back to keep up with what is getting done and what isn’t.

The third talk was a case study of a project delivered in NSW police by Peter Stanford of Artefaction called Architecting change – from Here to Eternity, or Agile and Now. This talk centred around the problems of getting consensus on big decisions in large, complex and diffuse organizations. The guts of the answer seemed to be making the decisions frequent and small, and using prototypes wherever possible.

On Day 2 I filled in for Paul Culmsee who was unable to attend – and did an ‘intimate’ Q&A session for two tables of people who wanted to ask questions about implementing agile practices. Matt Hodgson and Peter Stanford also sat in answering questions. It was fun and the people there seemed to like the more interactive nature of a conversation over yet another lecture.

The rest of the session was really interesting with lots of good content and speakers. I was happy I went and recommend anyone in Australia (or NZ) to pop along to the Sydney event on the 17th and 18th of August.

(Also posted at www.BetterProjects.net)

Blurring the Lines between Business and IT

Derek Roos — Thu, 21 Jan 2010 10:51:00 GMT

A “What If” question for business analysts and IT professionals…

What if it suddenly became very easy for someone to do both your job and their own, at the same time? If history provides any forecast for the future of IT, we are likely to see some interesting changes in the way human capital is managed – especially for those of us involved in the emergence of cloud computing. Clouds push complexity to the background and allow users to focus on what really matters: functionality and costs.

Have you ever noticed how the education we receive often sets boundaries in our career aspirations? We are trained to do something, and do it well – but in doing so, we take for granted the fact that others are doing the same thing in a different field. Then, when we are faced with an inevitable change, we instinctively take a “That’s not what I’ve been trained to do, there are other people for that” mentality. Sure, there are the motivated few who push down boundaries and become renaissance men and women in their own right. But when everyone else is set in their ways, these people are often considered a risk… think: too many eggs in one basket.

Now, to regress from my pseudo-philosophical banter, this trend is becoming all the more apparent as business analysts become more involved in technical training. Most IT veterans would say that business analysts will never have the true know-how to implement their plans, requirements and recommendations. The modern business analyst usually considers themselves more of a problem solver than a programmer – hence the separation of labor in this function of any business. Having surveyed the blogosphere for opinions of business analysts and IT professionals, there seems to be a live (and even a bit emotional) discussion between those who say it is a natural, and therefore inevitable, progression and those who say it is a “pie in the sky” and that it will never happen.

Contrastingly, a growing population of believers has something to say about the segregation of business and IT. In a world of zeros and ones, the innumerable coding languages can only become more and more efficient. As coding languages are continuously created, survival of the fittest can account for the extinct languages of modern programming. An abstraction of these languages is an ongoing phenomenon with a light at the end of the tunnel. Some say that using abstract, visual and human-readable models instead of low-level code is a very important step towards commoditized coding.

I’ve come to think about this abstraction phenomenon as measure to increase efficiency. When our ancestors realized that making bricks was faster than packing sand, they were on to something similar. If someone else uses molds to make perfectly shaped bricks that can be built into any structure, the workers need different skills but can ultimately build more economically, the architect can plan more accurately, and the buyer can move in earlier. So, why deal with sand when we can get the bricks from vendors elsewhere. Why deal with code, when we can get software modules elsewhere? This, my friends, may be the future of today’s business analyst. In the future, what if business analysts had the skill set and the molds to create bricks that satisfy their requirements without the need to deal with code – or sand?

Derek Roos
CEO
www.mendix.com

Slideshow: Agile for Analysts

Craig Brown — Mon, 30 Mar 2009 12:17:00 GMT

Agile for the rest of us

Agile plus Prince2

Craig Brown — Fri, 13 Mar 2009 12:07:00 GMT

My view is that you are making a serious compromise to the potential benfits of swapping across to agile methods if you hang on to a traditional pm process like PRINCE2, but others have different views.

Here is one from New Zealand (I think.)

Test driven development

Craig Brown — Sun, 08 Mar 2009 04:18:00 GMT

Test driven development is not actually a test methodology. It's a design philosophy that says "start with the end in mind" (Thank you Mr Covey.)

Here is a slideshow introducing some of the concepts and ideas within the agile method called Test Driven Development.

Test Driven Development Tutorial:

Scrum in one hour

Craig Brown — Wed, 04 Mar 2009 10:28:00 GMT

Here is the co-author/assembler of the scrum process describing it at Google. It's a more in-depth description of the process.

Check back with the last agile post's questions and think about whether this presentation has given you a deeper understanding.

Agile Business Analysis using UML

Gil — Thu, 26 Feb 2009 20:41:00 GMT

Following the lead of another forum, where the question was asked about the use of UML by Business Analysts, I would like to ask the same question when we come to Agile Analysis.

The answer is NOT simple and like all professional questions needs analysis. This means, I shall post a series of these blog pages, expanding one point at a time. I will NOT rush in and give you the answer now.

Business Analysis is a coat of many colours:
- It starts with the real business professional or consultant. They are masters of politics, hand waving and general waffle. Above all they speak 'Management speak' and that certainly does NOT include a solid diagramatic approach. They know that 'If a person has time to read a document, they are NOT a manager.' It is the members of this group who very often help make the decision to start a program of work on computer systems to meet some business. requirements. These are the people who read the documents aimed at managers. They are really Business Consultants.
- Then there are Real Business Analysts. These guys map out how the business works and how to change it. BPR is a term I most often associate with them. Producing a spec for a software system is something they can do if the need arises. BPMN is probably central to the diagramatic aspects of their work. Costing floor space, business growth etc is as important They do NOT need two products doing the same job, so UML is one of the many methods they need to know about without needing to be able to use it.
- Next comes the Computing Business Analyst. They analyse the business, including mapping Business Processes and identifying Business Requirements. They may also produce Business Requirements Documents, or respond to them with System Specifications, responses to tender. They work on the basis that if there is a relevant Business Process, it MUST be documented. This documentation is often very helpful to a person doing a full analysis of a Business requirement. They differ largely from the 'Real Business Analyst' in that they are brought onto a project in order to help create a new computer product; Real Business Analysts, are interested in how the business will respond to such a computer system, and the computing side is just a small part of their job.
- Finally, there is the Business Systems Analyst, for whom the Business Process Diagram is a necessary evel that they may sometimes have to resort to. These are the guys who really should be using UML. They should define the requirements for the computer system and ensure that someone designs and builds them. This is also the group that will have the greatest trouble talking to the potential end users, the project sponsors and the senior management.

These categories have been mapped out, just to show that the question is NOT a simple as it seems. You need to start with the definition of what or who a Business Analyst is. NO two BAs are ever the same. NO one BA ever does the same job twice. There are many shades of grey.

This changes the question from 'Should BAs use UML? into 'When should BAs use UML, if at all?

Finally, I will leave you with a thought for the next page. 'Do Business Analysts ever Analyse?'

Gil

Scrum in 5 minutes

Craig Brown — Thu, 26 Feb 2009 10:23:00 GMT

This 5 minute video explains the basics of the scrum process. Scrum is one of, if not THE most, popular agile method.

This process raises a few questions:

As a BA are you more suited to the role of scrum master, product owner or team member?
How do you change the way you manage requirements when you are targetting small increments of product rather than large ones?
How do you integrate the requirements elicitation and analysis work with the development process?
How do you have to change the way you analyse requirements to work with a product backlog?

Agile, erm, yeh sure... I know what you are talking about

Craig Brown — Sat, 21 Feb 2009 13:10:00 GMT

Guys and gals

Observing the forum here and industry discussions there appears to be some radical changes going on that are being ignored by the BA community.

It appears to me that the BA community is largely ignoring this Agile revolution.

Is this true? Are you ignoring it and focusing on getting your job done, and maybe even doing it better, but pretty much ignoring the agile community of methods and techniques?

Over the next couple of weeks I'll post up some YouTube clips and Slideshare decks explaining some of the more common agile methods.

If you want to keep working in IT projects over the next few years you'll need to understand what is going on and how it will change your job and career prospects.

I'll also open up a discussion thread in the forum where you can go and discuss your thoughts.

Craig

www.betterprojects.net

Software project methodologies

Craig Brown — Sun, 18 Jan 2009 09:26:00 GMT

Jurgen Appelo runs a blog at Noop.nl. He posted a summary on some project methods. I migrated them into a ppt for slideshare.

I hope this is intereting for you.

Software Project Methods

The Beginning of an Agile Team

Chase Petsche — Sun, 11 Jan 2009 20:37:00 GMT

I work for a rather large insurance company. We aren't the largest, but we are big enough to have our own SDLC (System Development Lifecycle) that comes packed with paper work, protocol and bureaucracy. Do not misunderstand me - these processes ensure the projects that are active are delivering on time and within budget. My last two efforts 20,000+ hours each have both come in a -2% of budget and were delivered on time. This has been largely due to the depth of documentation in terms of business requirements and tech design that had been accomplished by the time we needed to provide Execution estimates. Pretty remarkable in my opinion. So, what is the problem? Namely 14 months of project work before ANY benefit was delivered to our business partners. We changed direction with this last project - we are trying something new, and even though we've had our fair share of challenges, bumps and bruises, I'm happy with how we've progressed.

It all started when our estimates for delivery based on some scope definition and identification of high-level requirements landed us in July of 2009 - these estimates were given in August of 2008. Our project was denied the approval to continue. We were told to go back and figure out how to deliver in December 2008 or very early first quarter of 2009. Being challenged on estimates is just part of the game, but being asked to cut the effort in half and deliver the same quality of product in half the time is very difficult, if not impossible; we just don't inflate our estimates enough to trim that much fat.

Faced with this challenge, I started researching different project methodologies, different approaches, new ideas. Eventually this search landed me squarely on Agile Development. I pitched the idea to my project manager.

A couple of days later all main players of the project team were assembled. Architects, designers, developers, business analysts, business partners, project management and quality assurance were all together under one room. We reviewed the outlined objectives and in two days had an informal model of the end-state drawn up on a whiteboard. We broke the project into releases and timeboxed iterations (reqs, code, testing) to one month. Release 1 (we term 'Bare Minimum') comprised of the fewest changes needed to deliver an acceptable level of functionality to our business partners.

Release 1 is schedule to transfer later this month - not July. We will have delivered the major infrastructure needed within four iterations. The 2nd release will be within the following month - much quicker. I have a feeling that's how this project will start progressing. With the major infrastructure in place we should be able to role releases out very quickly!

We have learned many, many, many valuable lessons along the way. I'll write about those a separate time. I've been asked by others in our enterprise (different divisions than me) how I was able to persuade the executive sponsors to move to a iterative approach. I think it was a combination of a couple different factors: 1) serious time constraints, our business partners knew it and were willing to try something new; 2) willingness by a few to research, learn and introduce the team to iterative/agile principals; 3) a talented IT team who is willing, able and hungry to try new challenges and succeed in new ways.

Chase Petsche, BA III

Invest in User Stories

Craig Brown — Fri, 09 Jan 2009 12:01:00 GMT

User stories have a place in modern requirements management. They may not be going to replace use cases but you shoulod know how to write them well.

Invest In Good User Stories

View SlideShare presentation or Upload your own. (tags: agile scrum)

Agile Business Analysts?

Craig Brown — Wed, 28 Nov 2007 18:17:00 GMT

Do Business Analysts belong on Agile Projects? Some say yes, but isn't a better model for Agile developers to learn BA skills?

Don’t be fooled. Agile projects threaten the role of business analysts on IT projects.

An important thing to consider for Agile projects is that users need to be senior enough to be able to look beyond local agendas at broader business benefit.

Furthermore, the BA can be the one to add that broad view, but can't replace the senior user, as unless they have worked in the role they can't really know it. Additionally the business unit hasn't ‘bought in’ to the new system if done by proxy through a BA. The business definitely needs to send in their user/s.

We had a short discussion about this topic at Better Projects a while back and the consensus was that a BA can't replace the business representative on an Agile project – mainly for the above reasons.

In fact, on Agile projects the developers are expected to do the analysis in an agile project. That’s why they require A-grade team members and work best in less complex business environments.

Potentially a Business Analyst can participate in the team to add depth and skill to the analysis. Certainly they could be working on the next (or future) iterations while the development team are busy building this round.

Another alternative is that the skills of the business analyst are adopted by Agile developers. Teaching Agile development teams the disciplines of business analysis will help them accommodate more complex business environments and deliver more consistent results and in the end better projects.

What are your thoughts?

Business Analyst Community & Resources | Modern Analyst

Business Analysis in the Age of AI

Reinventing the Annual Member Survey: A Business Analyst’s Role in Delivering Actionable Insights

DOR & DOD: The BA’s Compass in Agile Delivery

Embracing Agility: The Evolving Role of Business Analysts

Secure by Design: Why Security Shouldn't Be an Afterthought in Software Development

Blueprints for Success -Pierre Hadaya talks business architecture and strategy

Background

Three key topics from my conversation with Pierre:

1. The Role of Hobbies and Interests in Shaping a Professional Outlook:

2. Career Trajectory:

3. The Future of Business Architecture and Strategy:

Key learning points:

Conclusion

BA thoughts: Communication & Documentation

What are your burndown charts telling you

Acceptance Criteria. Bridge from your User Stories to Code and Test Cases

Problem statement

Solutions

Old style

Nowadays dilemma

Bullet points

Gherkin language

Conclusion

Related articles

Author

Does Agile need Architecture to be successful?

Modeling your way to a great backlog

The Case for System Documentation aka "Developer Is No Longer King"

Agile investigated - Back to basics and beyond.

Applying Agile principles to requirement analysis

Agile is an attractive word

Satisfy Requirements with Continuous End User Involvement

Coaching Football and Agile Applications: It’s Game Time

Game Planning

Adjustments

How does this all tie together?

Challenges with User Stories

The Agile Application Assassin

Moving to Agile Documentation – why ‘Pair Inspections’ make sense

Enter the Business Engineer: Part 2

Telecom Companies are ready for the Cloud

Mendioms for Business Analysts

Visual Modeling – Stopping IT Failure at the Root of the Cause

Enhance Collaboration, Improve Requirements

The Immediate Feedback Loop

BA World Sydney - A review

Blurring the Lines between Business and IT

Slideshow: Agile for Analysts

Agile plus Prince2

Test driven development

Scrum in one hour

Agile Business Analysis using UML

Scrum in 5 minutes

Agile, erm, yeh sure... I know what you are talking about

Software project methodologies

The Beginning of an Agile Team

Invest in User Stories

Agile Business Analysts?